Configuration du serveur EMu
Cette section décrit la configuration du serveur EMu requise pour utiliser OpenID Connect.
Comptes d’utilisateurs
Les détails du compte utilisateur étant gérés par le prestataire d’identité, aucun compte utilisateur Unix côté serveur n’est nécessaire pour utiliser OIDC. Le compte d’utilisateur emu est toutefois toujours nécessaire pour l’administration côté serveur.
Si les fichiers Unix traditionnels passwd ou shadow sont utilisés pour l’authentification de l’utilisateur côté serveur emu, il ne devrait pas être nécessaire d’installer les bibliothèques Pluggable Authentication Module (PAM) requises pour prendre en charge d’autres méthodes d’authentification telles que Lightweight Directory Access Protocol (LDAP) ou Active Directory (AD).
Configuration du prestataire d’identité
Une entrée pour chaque prestataire d’identité doit être ajoutée au fichier de configuration de Texpress $TEXHOME/etc/openid/providers. Le fichier providers doit être formaté comme une collection JavaScript Object Notation (JSON). Chaque élément de la collection est un objet qui représente un seul prestataire d’identité. Les éléments d’objet suivants doivent être spécifiés pour chaque prestataire :
|
Élément |
Exigence |
Détails |
|---|---|---|
|
|
Optionnel |
Spécifie le titre utilisé pour identifier l’entrée. Peut être n’importe quelle valeur mais doit identifier le prestataire. Par exemple : Prestataire d’identité Azure pour EMu |
|
|
Optionnel |
Spécifie la valeur https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/v2.0/.well-known/openid-configuration Si cette valeur n’est pas fournie, vous devez fournir un élément |
|
|
Obligatoire |
Spécifie la valeur 11111111-1111-1111-1111-111111111111 |
|
|
Obligatoire |
Confirmez l’émetteur (c.-à-d. le prestataire d’identification) des jetons d’identification transmis au serveur. Par exemple : https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/v2.0 Cette valeur peut être extraite de $ curl --silent ’https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/v2.0/.well-known/openid-configuration’| jq ’.issuer’"https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/v2.0" Note: L’utilitaire |
|
|
Obligatoire |
Indiquez le nom du fichier utilisé par le serveur pour mettre en cache les données de découverte téléchargées. Il peut s’agir de n’importe quelle valeur, mais elle doit être différente de celle des autres prestataires azure.jwks |
|
|
Optionnel |
Utilisé pour la vérification du jeton lorsqu’une valeur |
Note: Vous trouverez de plus amples informations dans le fichier $TEXHOME/etc/openid/README.
Exemple
Voici un exemple complet d’un fichier providers pour les prestataires d’identité Microsoft Azure AD et Google Cloud Platform :
[
{
"name": "Azure Identity Provider for EMu",
"discovery": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/v2.0/.well-known/openid-configuration",
"client_id": "11111111-1111-1111-1111-111111111111",
"issuer": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/v2.0",
"jwksfile": "azure.jwks"
},
{
"name": "Google Identity Provider for EMu",
"discovery": "https://accounts.google.com/.well-known/openid-configuration",
"client_id": "111111111111-11111111111111111111111111111111.apps.googleusercontent.com",
"issuer": "https://accounts.google.com",
"jwksfile": "google.jwks"
}
]
Configuration du nom d’utilisateur
Le nom d’utilisateur attribué par le prestataire d’identité via OIDC est probablement l’adresse e-mail de l’utilisateur et doit correspondre au nom d’utilisateur côté serveur spécifié dans le Registre EMu.
Ceci n’est pas un problème pour les nouveaux utilisateurs ou les nouvelles installations mais peut être problématique pour les utilisateurs existants, car le nom d’utilisateur déjà spécifié dans le Registre EMu peut ne pas correspondre au nom d’utilisateur attribué par le prestataire d’identité.
Ce problème peut être résolu en utilisant la fonction Texpress Username Map, qui permet de faire correspondre un nom d’utilisateur OpenID à un autre nom d’utilisateur.
Cette fonction vous permet de changer le nom d’utilisateur attribué par le prestataire d’identité en un autre nom d’utilisateur après une autorisation réussie via OpenID Connect. Cette fonction est surtout utile pour faire correspondre un nom d’utilisateur OpenID au nom d’utilisateur d’un utilisateur déjà existant.
Attention
Il ne devrait pas être nécessaire d’utiliser la fonction Username Map pour les nouveaux utilisateurs ou les nouvelles installations d’EMu.
Les avantages de cette approche sont les suivants :
- Les entrées de Registre existantes de l’utilisateur n’ont pas besoin d’être mises à jour.
- Étant donné que le nom d’utilisateur non-OpenID des utilisateurs existants sera présent dans le système (par exemple dans les valeurs de la colonne Sécurité au niveau de l’enregistrement, éventuellement dans les valeurs de la colonne Inséré/Modifié par et la valeur de la colonne Utilisateur du module Audit), le système ne comportera pas deux noms d’utilisateur différents pour le même utilisateur.
Le Username Map est spécifié dans le fichier $TEXHOME/etc/openid/usermap. Chaque plan est spécifié sur une seule ligne et doit être formaté comme suit :
<nom d’utilisateur OpenID> <nom d’utilisateur> <nom complet optionnel>
Par exemple, la ligne suivante est utilisée pour mapper le nom d’utilisateur OpenID Charlie.Brown@peanuts.com au nom d’utilisateur existant charlieb :
Charlie.Brown@peanuts.com charlieb
Note
Le nom d’utilisateur existant (par exemple charlieb ci-dessus) ne doit pas nécessairement être un nom d’utilisateur Unix valide, c’est-à-dire qu’il ne doit pas nécessairement y avoir un compte Unix spécifié pour cet utilisateur sur le serveur EMu.
Vous trouverez de plus amples informations dans le fichier $TEXHOME/etc/openid/usermap.
